feat(sender): add 1080p capture profiles for non-Retina 1080p receivers - #168

Why

Every 21.5-inch iMac that is not a Retina 4K model has a native 1920 × 1080 panel,
and the lowest stream profile today is 1440p. Those receivers therefore have to
downscale every frame, which costs decode headroom on exactly the machines that
have the least of it, and the desktop never lands on the panel at its true size.

Decode load in pixels per second, against the existing profiles:

Both new profiles sit at or below standard1440p, which is already the comfortable
setting on older receivers.

What changed

feat(sender): add 1080p capture profile — adds standard1080p (30 FPS,
20 Mbps) and smooth1080p60 (60 FPS, 30 Mbps), titled Full HD and Full HD 60.
Bit rates follow the existing bits-per-pixel scaling, and both keep H.264 with the
same opportunistic HEVC upgrade the other sub-4K profiles use. Aliases 1080p,
1080, fullhd, 1920x1080, 1080p60, fullhd60 and smooth1080 are wired
into --preset, with strings added to all five language files.

feat(display): render 1080p profiles at native 1x scale — the profile alone
is not enough to make the feature work, because the virtual display geometry does
not come from the capture profile.

The receiver advertises a fixed 5120x2880 panel with a 2560x1440 HiDPI mode and
"hiDPI":true regardless of the display it is attached to
(TargetBridge-Receiver/TBReceiverC/src/main.c). The sender takes those values as
the virtual display geometry, so a 1080p stream was captured from a 1440p HiDPI
desktop and rescaled twice on the way to a 1080p panel.

Render matching does not fix it either: it sizes the backing store to the stream
but keeps the strictly 2x HiDPI contract, so 1080p becomes a 960×540 desktop.
Capture is 1:1, but every control is drawn at 2x on a panel with no extra pixels to
resolve it.

So TBVirtualDisplayModeSize gains an explicit isHiDPI, defaulting to the
existing 2x behaviour, and the capture profile chooses. The 1080p profiles declare
native scale and get a 1920x1080 1x mode. Every other profile is untouched and
still derives its mode and HiDPI flag from the receiver profile.

The trigger is the profile rather than the receiver's reported panel size, because
that value is a compile-time constant on the receiver and cannot distinguish a
1080p panel from a 5K one. If you would rather the receiver reported its real panel
and the sender keyed off that, I am happy to rework it that way — it would be the
more general fix, but it needs a receiver change and a protocol story for older
receivers, so I kept this PR sender-only.

Testing

Sender: MacBook Pro, Apple Silicon, macOS 26.5.2, Xcode 26.6.
Receiver: iMac10,1 21.5-inch (Core 2 Duo E7600, GeForce 9400, 1920×1080 panel)
running macOS 11.7.10 via OpenCore Legacy Patcher, over a direct Ethernet link.

• standard1080p runs stable and fluid, and the desktop now reaches the panel at
  its true size — verified with system_profiler SPDisplaysDataType showing the
  virtual display at 1920 × 1080 rather than the previous 2560 × 1440.
• smooth1080p60 runs and is usable, though not as smooth as standard1080p on
  this particular receiver.
• Unit tests added for the alias parsing and for the 1x/HiDPI backing-store maths.
  Full suite passes from a clean checkout.

Note, not part of this PR

On this receiver the session negotiates HEVC, because supportsHEVCDecode is
reported true, but a GeForce 9400 has no HEVC decoder and the work lands in
software. That affects standard1440p equally and is not introduced here, so I
have left it alone rather than widen this PR. Happy to open a separate issue.